\begin{sloppypar}
In addition to the production of FrameNet as a LOD lexical dataset that can be
accessed and queried over the Web of Data, 
%******** REVIEW ***************
% ISSUE 15
% Block added by Andrea
our aim is to provide an interpretation of frames as Knowledge Patterns (KP), as
they are defined by ~\cite{clark00knowledge} and ~\cite{GangemiPresutti10}.
In other words, following ~\cite{GangemiPresutti10}, we promote frames to relevant units of meaning for knowledge representation.
% End of block
\newline
With reference to Figure~\ref{method}, we have called this process TBox
refactoring, because a new ontology schema (a TBox), is obtained starting from data (ABox).\newline
The main problem with TBox refactoring is deciding the formal semantics to assign
to the classes from the FrameNet LOD dataset schema. Since this is a relatively arbitrary process, SemionRules and recipes are useful to configure alternative choices or to compare the different assumptions made by knowledge engineers. Here we present a refactoring experience that exemplifies the design method behind such process, and how Semion is useful in supporting it. The recipe exemplified here is part of a larger project carried out together with FrameNet developers in Berkeley in order to optimize the refactoring from lexical frames to knowledge patterns: as such, it certainly bears validity, but it is mainly intended as a methodological and pragmatical description of refactoring recipes (also called \textit{correspondence patterns} in ~\cite{DBLP:conf/ic3k/Svab-ZamazalSS09}).\newline
Besides the basic assumptions reported in section \ref{framenet}, this process is guided by the Book~\cite{fn2}, which is quite explicit about possible formal semantic choices:
\begin{quote}
The most basic summarization of the logic of FrameNet is that Frames describe classes of situations, the semantics of LUs are subclasses of the Frames, and (...) FEs are classes that are arguments of the Frame classes. An annotation set for a sentence generally describes an instance of the subclass associated with an LU as well as instances of each of its associated FE classes (...) The term ``Frame Element'' has two meanings: the relation itself, and the filler of the relation. When we describe the Coreness status of an FE (...) we are describing the relation; when we describe the Ontological type on an FE (...) we mean the type of the filler.
\end{quote}
According to these statements, a fragment of the \textbf{Desiring} frame is transformed into OWL as follows (in  Manchester syntax):
{\small 
\begin{verbatim}
Ontology: odpfn:desiring.owl
Annotations: 
    cpannoschema:specializes odp:situation.owl
Class: desiring:Desiring 
    SubClassOf: 
        desiring:hasEvent some desiring:Event,
        desiring:hasExperiencer some desiring:Experiencer,
        desiring:hasDegree some desiring:Degree,
        desiring:hasReason some desiring:Reason,
Class: desiring:covet.v
    SubClassOf: desiring:Desiring
Class: desiring:Event
    SubClassOf: semtype:State_of_Affairs
Class: desiring:Experiencer
    SubClassOf: semtype:Sentient
\end{verbatim}}
Notice that the uniqueness (\textit{locality}) of frame elements and lexical units for a frame is obtained simply by means of a specific namespace (denoted by the \textit{desiring} prefix in the example, see below for possible namespace policies), while a frame is interpreted as an owl:Class, lexical units as its subclasses, frame elements as both an owl:Class (e.g. \textit{Event}) and an owl:ObjectProperty (e.g. \textit{hasEvent}), the relation between a frame and a frame element as a rdfs:subClassOf an owl:Restriction, and the semantic type assignments to frame elements as additional subclass axioms. All knowledge patterns derived from frames are considered specialization of the generic pattern \texttt{odp:situation.owl}\footnote{\small{odp:http://www.ontologydesignpatterns.org/cp/owl/, odpfn:http://www.ontologydesignpatterns.org/cp/owl/fn/}}, which generalizes the situation semantics suggested by Berkeley linguists.\newline
A central role in FrameNet is played by \textit{inheritance} assumptions. In~\cite{fn2}, inheritance is viewed as 
\begin{quote}
the strongest relation between frames, corresponding to is-a in many ontologies. 
With this relation, anything which is strictly true about the semantics of the Parent must correspond to an equally or more specific fact about the Child. This includes Frame Element membership of the frames (except for Extrathematic FEs), most Semantic Types, frame relations to other frames, relationships among the Frame Elements, and Semantic Types on the Frame Elements.
%Properties of the Parent which are not strictly semantic in nature, such as not being evoked by lexical units (i.e. the Semantic Type Non-lexical frame), being evoked by a particular set of Lexical Units, or having a See also relation to another frame, are not inherited.
%Also, when there is a Core-set or an Excludes relation among Frame Elements of the Parent, these constitute disjunctive properties of the Parent. The Child frame may legitimately inherit only a subset of these disjunctive Frame Elements.
\end{quote}
This means that additional axioms must be wrapped into ontologies derived from frames, e.g. these two sample axioms are derived from the \textit{inheritsFrom} relation between the \textbf{Aesthetics} and \textbf{Desirability} frames as well as from the \textit{subFE} relation between some of their frame elements:
{\small 
\begin{verbatim}
Ontology: odpfn:aesthetics.owl
Annotations: 
    cpannoschema:specializes odpfn:desirability.owl
Class: aesthetics:Aesthetics
    SubClassOf: desirability:Desirability
Class: aesthetics:Degree
    SubClassOf: desirability:Degree
\end{verbatim}}
The implementation of TBox refactoring is performed as a Semion refactoring, where the
recipe includes rules for the mapping between FrameNet LOD dataset and
KPs. Figure~\ref{frameCP} shows an overview of TBox refactoring
for deriving KPs from frames. 
\begin{figure}[h!]
\centering
	\includegraphics[scale=0.25]{img/frameCP.png}
	\caption{Diagram of the transformation recipe used for
	the production of knowledge patterns from FrameNet LOD.}\label{frameCP}
\end{figure}
The notation attempts to make rules intuitively understandable:
arrows between the clouds represent mappings from entities in the cloud ``FrameNet
as LOD'' to entities in the cloud ``Knowledge Pattern'', classes are represented as circles, individuals as triangles, object properties as diamonds, and structural properties as labeled arcs. 
Each \textit{Frame} is mapped both to an \texttt{owl:Ontology} that identifies
the KP and to an \texttt{owl:Class}. The mapping takes into account the refactoring
of the frame URI intended either as an
ontology or as a class. Each \textit{FrameElement} maps both to
an \texttt{owl:Class} and to an \texttt{owl:ObjectProperty}. Again frame
elements follow a renaming policy for the two
interpretations, but in this case the situation is more complex. In fact,
URI policy can follow from different interpretations: 
\begin{enumerate}
\item \textit{Locality} of frame
elements within their frames (compatible to
locality statements in the Book, with some exceptions that cannot be discussed here). 
E.g. given the frame:\newline
\texttt{\small{http://someuri/Judgment.owl\#Judgment}}\newline
we obtain the frame element:\newline
\texttt{\small{http://someuri/Judgment.owl\#Cognizer}}\newline
interpreted as a class and\newline
\texttt{\small{http://someuri/Judgment.owl\#hasCognizer}}\newline
interpreted as an object property;\footnote{\small{An OWL2 alternative is also possible, with multiple interpretations for the same constant.}}
\item \textit{Globality} of frame elements, abstracted from their contextual binding to a frame, e.g. given the frame:\newline
\texttt{\small{http://someuri/Judgment.owl\#Judgment}}\newline
we obtain the frame element:\newline
\texttt{\small{http://someuri/class/Cognizer}}\newline 
interpreted as a class and\newline
\texttt{\small{http://someuri/property/hasCognizer}}\newline
interpreted as an object property.
\end{enumerate}
%Locality and globality alternatives for frame elements are also valid for 
Lexical units are refactored as
subclasses of the classes derived from the frames they are lexicalizations of, e.g. \newline
\texttt{\small{lexunit:cool.a SubClassOf: desirability:Desirability}}\newline
%Furthermore each \textit{owl:Class} derived from a lexical
%unit is interpreted as a sub class of, i.e. \textit{rdfs:subClassOf}, the class
%derived from the frame where the lexical unit occurred. 
%The occurrence of a lexical unit in a frame is simply detected querying the LOD dataset with
%&SemionRules for statements like \texttt{?frame fntbox:hasLexicalUnit
%?lu}.\newline 
Lexemes are refactored as individuals of the class
\texttt{semantics:Expression}; each lexical unit is related
to a lexeme through the property \texttt{semantics:isExpressedBy}.\newline
Finally, each frame has \texttt{owl:someValuesFrom} restrictions accounting for the semantic roles implicit in frame elements (see example above).\newline
%******** REVIEW ***************
% ISSUE 6
% Block added by Andrea 
Locality and globality alternatives required two refactoring recipies each of
one composed by 4 rules in forward-chaining inference mode. 
% End of block 
The complete TBox refactoring recipe can be found in the wiki
page\footnote{\small{http://stlab.istc.cnr.it/stlab/FrameNetKCAP2011\# tab=TBoxRefactoring}}.

\end{sloppypar}

